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IMPROVED MOBILE IP DEPLOYMENT 




The present invention relates to an advanced scenario for MIP deployment in UMTS/GPRS. It is 
discussed in the context of advanced deployment scenarios of MIP and how they fit in an evolutionary 
enario starting from a GPRS system deployment assumption. The disclosure is presented as a way to 
deploy mobile IP also to handle intra-system mobility. 
SUPPORT OF MOBILE IP: AN ADVANCED SCENARIO 
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In the picture above an advanced deployment scenario is depicted. In this case the IGSN performs a 
subset of the functionality performed by the combined SGSN and GGSN for mobile IP purposes. 
The goal to achieve is not to change 04.08 and to minimize the changes in GPRS standards. 
The session activation and initial registration is completely identical to the case in which the FA is 
placed at a GGSN [see Tdoc s2m99036]. It is assumed that every IGSN is equipped with a FA. The 
IGSN may be an SGSN that behaves in a different way when the APN specified in the PDP context 
activation request or in the subscription data selects Mobile IP mode of operation. Instead of sending a 
PDP context Activation request to a GGSN. the IGSN sends a PDP context Creation Response to the 



mobile terminal and triggers a FA to send the advertisement to the Mobile station that is requesting the 
activation of a session, in the same way as it is done when the FA is at the GGSN. 



The difference with respect to the case where the FA is at a GGSN non colocated with the SGSi^s in 
that inter-IGSN mobility is handled by mobile IP, with the optional support of existing SGSNm*<Mc 
functionality in order to transfer packets from one IGSN to another when handover occurs. 
In the sequel, RA update procedures are described. The approach chosen is to highlight the differences 
with respect to current specs (in particular with what is written in GSM TS 03.60, from which the text 
is drawn). 

INTER IGSN ROUTING AREA UPDATE 



Note: throughout this section, wherever the word 'SGSN' is met, it must be considered as a SGS? 
functionality. We do not imply or suggest the IGSN to be only an SGSN. The transfer of packets from 
the old IGSN to the new IGSN may be deemed not necessary, or not required because of Mobile IP 
standard evolution. 
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1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type) 
to the new SGSN. Update Type shall indicate RA update or periodic RA update. The BSS shall 
add the Cell Global Identity including the RAC and LAC of the cell form where the message was 
received before passing the message to the SGSN. 

2) The new SGSN sends SGSN Context Request (old RAI, TLLI, old P-TMSI Signature, New 
SGSN Address) to the old SGSN to get the MM and PDP contexts for the MS. The old SGSN 
validates the old P-TMSI Signature and responds with an appropriate error cause if it does not 
match the value stored in the old SGSN. This should initiate the security functions in the new 
SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an 
SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message 10 the old 
SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI 
Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN 
responds with SGSN Context Response (MM Context, PDP Contexts, LLC Ack). If the MS is 
not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old 
SGSN stores New SGSN Address, to allow the old SGSN to forward data packets to the new 
SGSN. LLC Ack contains the acknowledgements for each LLC connection used by the MS. Each 
PDP Context includes the GTP sequence number for the next downlink N-PDU to be sent to the 
MS and the GTP sequence number for the next uplink N-PDU to be tunnelled via mobile IP 
tunnel to the HA. The old SGSN starts a timer and stops the transmission of N-PDUs to the MS. 

3) Security functions may be executed. These procedures are defined in subclause "Security 
Function". Ciphering mode shall be set if ciphering is supported. 

4) The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. This informs 
the old SGSN that the new SGSN is ready to receive data packets belonging to the activated PDP 
contexts. The old SGSN marks in its context that the MSC/VLR association and the information 
in the HLR are invalid. This triggers the MSC/VLR and the HLR to be updated if the MS initiates 
a routeing area update procedure back to the old SGSN before completing the ongoing routeing 
area update procedure. If the security functions do not authenticate the MS correctly, then the 
routing area update shall be rejected, and the new SGSN shall send a reject indication to the old 
SGSN. The old SGSN shall continue as if the SGSN Context Request was never received. 



5)The old SGSN duplicates the buffered N-PDUs and starts tunnelling them to the new SGSN. 
Additional N-PDUs received before the timer described in step 2 expires are also duplicated and 
tunnelled to the new SGSN. N-PDUs that were already sent to the MS and that are not yet 
acknowledged by the MS are tunnelled together with the number of the LLC fram^hat 
transferred the last segment of the N-PDU. No N-PDUs shall be forwarded to the ne^WN 
after expiry of the timer described in step 2. 



6) The new SGSN informs the HLR of the change of SGSN by sending Update Location 
(SGSN Number, SGSN Address, IMSI) to the HLR. 

7) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation 
Type set to Update Procedure. If the timer described in step 2 is not running, then the old SGS^E 
removes the MM and PDP contexts. Otherwise, the contexts are removed only when the timer 
expires. This allows the old SGSN to complete the forwarding of N-PDUs. It also ensures that the 
MM and PDP contexts are kept in the old SGSN in case the MS initiates another inter SGSN 
routeing area update before completing the ongoing routeing area update to the new SGSN. The 
old SGSN acknowledges with Cancel Location Ack (IMSI). 

8) The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the new SGSN. The 
new SGSN validates the MS's presence in the (new) RA. If due to regional subscription the MS is 
rejected, the SGSN rejects the Routeing Area Update Request with an appropriate cause and 
returns an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted Due To Regional 
Subscription) message to the HLR. If all checks are successful then the SGSN constructs an MJ 
context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 



9) The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new 
SGSN. 

10) The new SGSN validates the MS's presence in the new RA. If due to regional, national or 
international restrictions the MS is not allowed to attach in the RA or subscription checking fails, 
then the new SGSN rejects the routeing area update with an appropriate cause. If all checks are 
successful then the new SGSN constructs MM and PDP contexts for the MS. A logical link is 
established between the new SGSN and the MS. The new SGSN responds to the MS with 
Routeing Area Update Accept (P-TMSI, LLC Ack, P-TMSI Signature). LLC Ack contains the 
acknowledgements for each LLC connection used by the MS. thereby confirming all mobile- 
originated N-PDUs successfully transferred before the start of the update procedure. 




11) The MS acknowledges the new P-TMSI with a Routeing Area Update Complete 

(P-TMSL LLC Ack). LLC Ack contains the acknowledgements for each LLC connection used by 
the MS, thereby confirming all mobile-terminated N-PDUs successfully transferred before the 
start of the update procedure. If LLC Ack confirms reception of N-PDUs that were forwarded 
M from the old SGSN, then these N-PDUs shall be discarded by the new SGSN. LLC and SNDCP 
in the MS are reset locally. 

12) Over the newly setup link to the mobile, a Mobile IP Agent Advertisement is sent including 
challenge/response and NAI extensions This is triggered in some way not specified here and 
implementation dependent. 

It is sent only to the mobile performing the RA update. This is sent in such a way that subnet prefix 
based movement detection algorithm the Mobile IP spec [RFC2002] suggests triggers an 
immediate mobile IP registration (i.e. by making sure no two FA in the PLMN send 
advertisements with identical subnet prefixes). 

13) The normal MIP registration is performed. This will be periodically repeated according to timers 
negotiated in the registration, in order to keep the MIP session alive. 

In the case of a rejected routeing area update operation, due to Routeing Area restrictions, the new 
SGSN shall not construct an MM context. A reject shall be returned to the MS with an appropriate 
cause. The MS shall not re-attempt a routeing area update to that RA. The RAI value shall be deleted 
when the MS is powered-up. 

If the timer described in step 2 expires and no Cancel Location (IMSI) was received from the HLR, 
then the old SGSN shall stop forwarding N-PDUs to the new SGSN. 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN 
returns a Routeing Area Update Reject (Cause) message, the MS shall enter IDLE state. 
INTRA IGSN RA UPDATE 
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1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Typ 
to the SGSN. Update Type shall indicate RA update. The BSS shall add the Cell Global Identity 
including the RAC and LAC of the cell where the message was received before passing the 
message to the SGSN, see GSM 08.18. 

2) Security functions may be executed. These procedures are defined in subclause "Security 
Function". 

3) The SGSN validates the MS's presence in the new RA. If due to regional, national or international 
restrictions the MS is not allowed to attach in the RA or subscription checking fails, then the 
SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then 
the SGSN updates the MM context for the MS. A new P-TMSI may be allocated. A Routeii^| 
Area Update Accept (P-TMSI, P-TMSI Signature) is returned to the MS. 

4) If P-TMSI was reallocated, the MS acknowledges the new P-TMSI with Routeing Area Update 
Complete (P-TMSI). 

5) If the New routing area is under the domain of a new FA (e.g. for load sharing reasons) then a 
Mobile IP Agent Advertisement is sent including challenge/response and NAI extensions This is 
triggered in some way not specified here and implementation dependent. 
It is sent only to the mobile performing the RA update. This is sent in such a way that subnet 
prefix based movement detection algorithm the Mobile IP spec [RFC2002] suggests trigger an 
immediate mobile IP registration (i.e. by making sure no two FA in the PLMN send 
advertisements with identical subnet prefixes). 



6) The regular MIP registration is performed. This will be periodically repeated according to timers 
negotiated in the registration, in order to keep the MIP session alive. 

If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN 
Returns a Routeing Area Update Reject (Cause) message, the MS shall enter IDLE state. 

MOBILE IP SPECIFIC DETAILS 

The lifetime of the MIP registration should be set to a value » periodic RA updates interval (Timer 
T3312), so that the necessity to send MIP Registration does not arise more frequently than Periodic RA 
updates. 

The lifetime of a MIP advertisement should be set to a value > > T3312 as well, so that attempts to 
register are not more frequent than Periodic RA updates (a short Advertisement lifetime may require 
sending many advertisements over the air, or, missing this, it may trigger the mobile to re-register 
frequently, since the lifetime based movement detection algorithm may be triggered) . 
Periodic RA updates should not trigger MIP registrations. 
The UMTS case 

This part of the contribution addresses what could be done in UMTS when an SRNS relocation would 
happen. This does not provide low level details, and basically it's a modification of what is written in 
23.20. 

When the mobile is in idle mode, the procedures defined for GPRS works the same way in UMTS. 
When the mobile is in connected state, the following SRNS relocation procedure takes place. 
When the word "SGSN" is used, it is used to indicate a functionality and not a physical node. 
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UTRAN makes the decision to perform the Serving RNC relocation procedure. This includes 
decision on into which RNC (Target RNC) the Serving RNC functionality is to be relocated. 
The source SRNC sends SRNC Relocation required messages to the SGSN1. This message 
includes parameters such as target RNC identifier and an information field that shall be 
passed transparently to the target RNC. 

Upon reception of SRNC Relocation required message the SGSN1 determines from the 
received information that the SRNC relocation will (in this case) result in change of SGSN. 
The SGSN will then send a Forward SRNC relocation request to the applicable SGSN ; 
SGSN2 ? including the information received from the Source RNC and necessary information 
for the change of SGSN (e.g. MM context, PDP context). 



The SGSN2 will send a SRNC Relocation Request message to the target RNC. This message 
includes information for building up the SRNC context, transparently sent from Source RNC 
(e.g. UE id., no of connected CN nodes, UE capability information), and directives for setting 
up Iu user plane transport bearers. 

When the Iu user plane transport bearers have been established, and target RNC completed its 
preparation phase, SRNC Relocation Proceeding 1 message is sent to the SGSN2. 

When the traffic resources between target RNC and SGSN2 has been allocated and the 
SGSN2 is ready for the SRNC move, then the Forward SRNC Relocation Response is sent 
from SGSN2 to SGSNl. This message indicates that necessary resources have been allocated 
for the SRNC relocation. 

When the Forward SRNC Relocation Response has been received in the SGSNl, the SGSNl 
indicates the completion of preparation phase at the CN side for the SRNC relocation by 
sending the SRNC Relocation Proceeding 2 message to the Source RNC. 

When the source RNC has received the SRNC Relocation Proceeding 2 message, the source 
RNC sends a SRNC Relocation Commit message to the target RNC. The target RNC 
executes switch for all bearers at the earliest suitable time instance. 

Immediately after a successful switch at RNC, target RNC (=SRNC) sends SRNC Relocation 
Complete message to the SGSN2. The SGSN will also send a Complete SRNC Relocation 
towards the SGSNl. 

At reception of the Complete SRNC Relocation, SGSNl will send a release indication 
towards the Source RNC. This will imply release of all UTRAN resources that were related to 
this UE. 

1) Over the newly setup link to the mobile (the target RNS is now acting as SRNS) a Mobile IP 
Agent Advertisement is sent including challenge/response and NAI extensions. This is 
triggered in some way not specified here and implementation dependent. 
It is sent only to the mobile performing the SRNS relocation. This is sent in such a way that 
subnet prefix based movement detection algorithm the Mobile IP spec [RFC2002] suggests 
triggers an immediate mobile IP registration (i.e. by making sure no two FA in the PLMN send 
advertisements with identical subnet prefixes). 



When the target RNC is acting as Mip 2) The normal MIP registration is performed. This will be 
periodically repeated according to timers negotiated in the registration, in order to keep the 
MIP session alive. 

9) SRNC, it will send New MM System Information to the UE indicating e.g. relevan^Bfctog 
Area and Location Area. Additional RRC information may then also be sent to the^^^g. 
new RNTI identity. 

10) The SGSN2 informs the HLR of the change of SGSN by sending Update GPRS location 
(IMSI, new SGSN address etc.) to the HLR. The HLR cancels the context in the old SGSN, 
SGSN1, by sending Cancel Location (IMSI). The SGSN1 removes the context and 
acknowledges with Cancel Location Ack. The HLR sends Insert subscriber data (IM^^ 
subscription data) to the SGSN2. The SGSN2 acknowledges with Insert Subscriber Data Ack: 
The HLR acknowledges the Update GPRS location by sending Update GPRS Location Ack 
to the SGSN2. 

11) At reception of Insert subscriber data from HLR, the SGSN2 will initiate the update of MM 
information stored in the UE. This is done by sending Network Initiated Routing Area Update 
Command to the UE. This message will include new RAI, and possible also new P-TMSI. 
When the UE has made necessary updates it answers with Network Initiated Routing .Area 
Update Complete. 

Before point (a), in Figure 19 ? the connection is established between UE and HAyia Source RNC an 
SGSN1. 

After point (b), in Figure 19, the connection is established between UE and HA via Target RNC and 
SGSN2. 



Claims 

1 . A mobile IP environment substantially as described herein with reference to or as shown in any one 
of the accompanying drawings. 

2. A method of operating or controlling a mobile IP environment substantially as described herein 
with reference to or as shown in any one of the accompanying drawings. 
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